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Abstract 

Good  documentation  is  critical  for  user  acceptance 
of  any  system,  and  empirical  studies  have  shown 
that  examples  can  greatly  inwease  effectiveness 
of  system  documentation.  However,  studies  also 
show  that  badly  integrated  text  and  examples  can  be 
actually  detrimental  compared  to  using  either  text 
or  examples  alone.  It  is  thus  clear  that  in  order  to 
provide  useful  documentation  automatically,  a  sys¬ 
tem  must  be  capable  of  providing  well-integrated 
examples  to  illustrate  its  points. 

Previous  work  on  example  generation  has  concen¬ 
trated  on  the  issue  of  retrieving  or  constructing  ex¬ 
amples.  In  this  paper,  we  look  at  the  injegreuion 
of  text  and  examples.  We  identify  how  text  and 
examples  co-constrain  each  other  and  show  that  a 
system  must  consider  example  generation  as  an  in¬ 
tegral  part  of  the  generation  process.  Finally,  we 
present  such  a  system,  together  with  an  example. 

1  Introduction 

Good  documentation  is  critical  for  user  acceptance  of  any  sys¬ 
tem,  and,  increasingly,  it  comes  in  both  conventional  manuals 
as  well  as  on-line  facilities.  These  are  often  based  on  hyper¬ 
text  or  similar  retrieval  methods.  Advances  in  areas  such 
as  knowledge-based  systems,  Natural  Language  Generation 
H'fLG)  and  multi-media  now  make  it  possible  to  investigate 
the  automatic  generation  of  documentation  from  the  underly¬ 
ing  knowledge  bases.  This  has  several  important  benefits:  it 
is  easily  accessible;  it  avoids  frequent  problems  of  inconsis¬ 
tency  (as  the  information  presented  is  obtained  directly  from 
the  knowledge  bases);  and  not  the  least,  it  can  take  the  user, 
and  the  dialogue  context  into  account. 

Examples  can  greatly  contribute  to  the  effectiveness  of 
documentation.  Empirical  studies  have  found  that  the  inclu¬ 
sion  of  examples  in  documentation  can  inaease  user  com¬ 
prehension,  e.g.,  [Reder  et  ai,  1986],  sometimes  by  as  much 
as  100%  [Chamey  et  ai.  1988].  In  order  to  provide  useful 
documentation  automatically,  then,  a  system  must  not  only 
generate  good  descriptions,  but  it  must  also  provide  examples. 
This  raises  at  least  two  issues:  (I)  finding  appropriate  exam¬ 
ples  and  (2),  making  effective  use  of  them.  While  the  first 
issue  has  been  investigated  previously,  e.g.,  [Rissland,  1980; 
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Rissland  etal.,\  984],  the  second  one  remains  largely  unstud¬ 
ied.  This  is  the  issue  we  are  addressing  in  our  effort  to  build 
a  user-oriented  documentation  facility  for  the  Explainable 
Expert  System  (EES)  framework  [Swartout  ei  al.,  19921. 

Building  on  work  in  psychology,  education,  computational 
generation  of  examples  and  NLG,  we  are  studying  how  text 
and  examples  interact  with  each  other.  In  this  pjq)er,  we  argue 
that  example  generation  should  be  considered  an  integral  part 
of  the  documentation  generation  process,  as  examples  must 
be  integrated  within  the  surrounding  text.  Indeed,  psycholog¬ 
ical  evidence  shows  that  badly  integrated  text  and  examples 
can  be  detrimental  compared  to  using  either  text  or  examples 
alone,  e.g.,  [Chandler  and  Swellcr,  19911.  We  present  a  text 
generation  system  that  achieves  this  integration  by  planning 
a  presentation  (text  and  examples)  taking  into  account  rele¬ 
vant  factors  in  the  generation  of  these  two  rhetorical  devices. 
Finally,  we  present  a  specific  example  from  our  system,  in 
which  documentation  about  a  specific  programming  language 
is  generated. 

2  Previous  work  and  Open  Issues 

There  have  been  considerable  efforts  in  analyzing  the  type  of 
examples  that  may  be  useful  to  present  to  the  user  (e.g .,  I  Mich  - 
ener,  19781),  as  well  as  in  deciding  whether  an  example 
should  be  retrieved  or  constructed,  and  on  bow  to  retrieve 
the  appropriate  example,  e.g.,  [Rissland  and  Ashley,  1986; 
Rissland,  1980;Suthersand  Rissland,  19881.  Other  work  has 
focused  on  when  to  present  examples  [Woolf  and  McDonald, 
1984].  However,  none  of  these  studies  looked  at  generating 
both  text  and  examples,  and  thus  did  not  look  at  the  issue  of 
ensuring  their  integration. 

In  NLG,  researchers  have  used  examples  as  one  of  the 
rhetorical  strategies  used  to  produce  texts,  e.g.,  [McKeown, 
1985;Moore,  19891,  but  did  not  address  the  issue  of  choosing 
the  examples  to  fit  a  specific  description  and  integrating  them 
into  the  text. 

Finally,  there  is  a  large  body  of  work  on  the  use  of  examples 
in  education,  e.g.,  [Houtz  et  ai,  19731,  cognitive  science  and 
psychology,  e.g.,  [Reiser  et  ai,  19851,  and  documentation, 
c.g.,  [Chamey  et  al.,  1988].  Although  much  of  this  work 
is  not  immediately  computationally  applicable,  it  suggests 
constraints  to  take  into  account  when  generating  texts  and 
examples. 

Our  work  builds  on  the  work  mentioned  above  and  our  own 
analysis  of  documentation  material  to  develop  a  system  that 
generates  appropriate  examples  in  the  context  of  a  surround¬ 
ing  text  to  form  a  coherent,  well -structured  presentation. 


A  LIST  coDtains  zero  or  more  pieces  of  data  elements.  Examples  of 
lists  are: 

( aardvaxk )  ;;  a  list  of  one  element 

(zed  jrelloe  green)  ;;  a  list  of  several  elements 
(2  3  S  11  19)  ;;  a  list  can  contain  numbers 

(3  french  fries)  ;;  data  elements  can  be  of 

;;  different  types 

Given  the  three  lists:  (1  2),  (3  4)  and  (6  6),  the  following  is 
also  a  list¬ 
ed  2)  (3  4)  (5  6))  ;;  a  list  can  contain  other  lists 

Figure  1:  Using  piompts  to  make  explicit  the  information 
contained  in  the  ordering  of  the  examples  [Touretzky,  1984]. 

3  Interactions  between  Text  and  Examples 

In  order  to  identify  the  relevant  factors  in  the  interaction 
between  text  and  examples,  the  system  must  consider  at  least 
the  following  points: 

1.  what  should  be  presented  through  text,  examples  or 
both? 

2.  will  there  be  one  or  multiple  examples?  If  more  than 
one  example,  how  many?  what  information  should  each 
one  convey?  How  should  they  be  ordered? 

3.  can  the  example  cause  additional  text  to  be  generated 
that  may  not  otherwise  have  been  presented? 

To  address  these  issues,  example  and  text  generation  have  to 
be  considered  together.  For  example,  to  decide  which  aspects 
of  the  presentation  should  be  illustrated  with  examples,  a  sys¬ 
tem  must  know  the  important  features  to  convey.  But,  feature 
importance  depends  upon  the  context,  and  is  based  on  factors 
such  as  the  type  of  text  (e.g.,  tutorial  vs  reference)  and  what 
the  discourse  is  about.  Much  of  this  information  is  important 
when  constructing  a  text  as  well,  and  will  already  be  available 
in  the  discourse  planning  context.  A  module  for  generating 
examples  can  thus  take  advantage  of  this  information. 

The  interaction  actually  goes  both  ways:  a  decision  on 
which  aspects  of  the  information  are  to  be  presented  through 
examples  affects  the  textual  description  as  well.’  Consider  for 
instance,  the  following  definition  of  the  lisp  concept  list: 

A  list  consists  of  a  left  parenthesis,  zero  or  more 
data  elements,  followed  by  a  right  parenthesis.  The 
data  elements  can  be  either  symbols,  numbers,  ora  com¬ 
bination  of  these  two  types. 

Compare  this  definition  with  that  in  Fig.  1.  In  the  figure,  the 
information  that,  above,  is  expressed  in  italics  was  instead 
communicated  through  examples. 

Another  source  of  interaction  occurs  when  an  example 
embodies  more  than  one  point,  or  when  a  group  of  examples 
illustrate  a  point  together.  In  such  a  case,  the  system  needs 
to  generate  a  prompt  (i.e.,  a  marker  focusing  attention  on  the 
points  being  made;  for  example,  the  comments  next  to  the 
examples  in  Fig.  1  are  prompts).  Since  these  prompts  can  be 
textual,  they  will  also  need  to  be  planned  by  the  text-planner. 
To  plan  them,  the  system  needs  to  know  not  only  what  the 
examples  illusu-atebut  also  what  is  implied  by  their  ordering. 
Consider  for  instance,  the  definition  in  Fig.  1.  The  examples 

’  Note  that  these  issues  are  similar  to  the  ones  that  arise  in  the 
planning  and  presentation  of  other  explanatory  devices  -  such  as 
diagrams,  pictures  and  analogies.e.g.,  (Feiner  and  McKeown,  199! }. 


illustrate  the  fact  that  the  data  elements  in  a  list  can  be  of 
different  types  and  in  any  number.  The  order  of  the  examples 
is  important  as  examples  are  introduced  from  simplest  to  most 
complex,  each  building  on  the  previous  one.  In  this  case,  the 
author  chose  to  make  explicit  the  information  that  is  implicit 
in  the  ordering  of  the  examples  and  included  a  comment  (a 
prompt)  for  each  example. 

Furthermore,  it  might  be  necessary  to  include  yet  more 
text  between  the  examples  to  ensure  the  coherence  of  the 
presentation,  or  in  order  to  set  up  an  example  properly.  This 
is  also  done  in  Fig.  1,  where  the  three  lists  (1  2),  (3  4), 
and  (B  6)  are  inuoduced  before  the  last  example. 

To  generate  coherent  descriptions  which  include  examples, 
the  generation  of  examples  must  thus  be  tightly  integrated 
within  the  generation  process:  text  and  examples  must  co¬ 
constrain  each  other.  In  the  next  sections,  we  describe  our 
documentation  context,  present  a  system  that  achieves  the 
desired  integration  and  illustrate  it  with  an  actual  scenario. 

4  Generating  integrated  explanations 

Our  system  is  part  of  the  documentation  facility  we  are 
building  for  the  Explainable  Expert  Systems  (EES)  frame¬ 
work  [Swartout  et  ai,  1992),  a  framework  fc  .  huildingexpen 
systems  capable  ofexplaining  their  reasoning  as  well  Lheir 
domain  knowledge.  In  EES,  a  user  specifies  a  domain  model 
(in  the  high  level  knowledge  representation  language  Loom 
[Mac(3regor,  1988P),  as  well  as  problem  solving  principles, 
i.e.,  methods  for  solving  problems  in  the  domain.  Given  these 
and  a  variabilized  goal  to  achieve,  EES  generates  an  expert 
system  to  solve  goals  of  the  same  form. 

The  problem  solving  methods  have  to  be  written  in  a 
specific  plan  language,  intend,  intent)  is  specified  in  the 
Backus-Naur  Form  (BNF).*  a  fragment  of  which  is  shown 
in  Fig.  2.  The  grammar  contains  productions,  and,  option¬ 
ally  'filter-functions’  on  the  productions,  i.e.,  tests  that  have 
to  be  satisfied  (for  instance  ‘pred-relation-form-iesi’  on  the 
pred-relation-fonB  production).^ 

The  grammar  of  intend  is  quite  complex,  and  thus  pro¬ 
vides  a  good  test-bed  for  a  documentation  facility.  With  such 
an  on-line  facility,  users  can  get  information  as  to  what  might 
be  wrong  when  a  plan  does  not  parse,  as  well  as  descriptions 
of  the  various  constructs  involved,  together  with  examples. 

The  documentation  for  the  grammar  symbol  predi¬ 
cate-form,  whose  bnt  definition  is  shown  in  Fig.  2,  is  shown 
in  Fig.  3.  Consider  the  examples  and  the  textual  explanation 
in  this  figure.  The  first  three  examples  are  positive,  while  the 
fourth  is  a  negative  example  (or  counter-example).  (All  of 
the  examples  are  from  our  domain  of  local  area  networks.) 
The  mutual  constraints  of  the  text  and  the  examples  can  be 
seen  again  in  many  places: 

1.  The  examples  illustrate  features  mentioned  in  the  text, 
namely  the  syntax  of  lhepredicat«-r«lation-form. 

^Loom  is  a  KL-ONE  type  language. 

’For  use  by  the  generation  facility,  the  graiiunar  is  transformed 
into  an  equivalent  form  in  Loom. 

‘Transforming  the  BNF  form  to  a  Loom  repre.sentaiion  was  a 
fairly  straightforward  task.  However,  the  filter-functions  on  th,e  pro¬ 
ductions  could  not  be  extracted  automatically.  These  were  annotated 
by  hand. 


B-form  :=  ’( 'IF  predicate-form  THEN  expression 
{ ’ELSE  expression  }  ’) ; 

restricted-expression  :=  var-name  |  cortcept-desc  I 
function-form  I  predicate-form ; 

predicate-form  :=  pred-relation-form  1 

pred-logical-form  I  pred-action-form ; 

pred-relation-form  := 

’( relation-name  restricted-expression  * ') 

I  >  pred-relation-form-tesl ; 

pred-action-form  :=  action-form  I  >  pred-action-test : 

pred-logical-form  := 

’{ 'AND  pradicete-form  +  ’)  I 

’{ 'OR  predicate-form  +  ’)  I  ’( ’NOT  predicate-form '}: 

function-form  ;= 

’( relation-name  restricted -expression  * ') 

|>  function-relation-form-test : 

Figure  2:  A  Cragment  of  the  intend  grammar. 

2.  The  first  three  examples  are  introduced  with  ‘back¬ 
ground’  text,  to  make  sure  they  are  understood  as  pos¬ 
itive  examples;  “Examples  of  predicate-relation-forms 
are 

3.  Because  the  positive  examples  are  introduced  with  text, 
they  occur  together,  rather  than  interspersed  with  the 
negative  example. 

4.  The  sentence  “However,  the  following  is  not  a  ...  ” 
is  generated  to  make  a  contrast  between  positive  and 
negative  examples. 

5.  The  negative  example  selected  causes  the  generation 
of  additional  text  both  before  and  after  the  presen¬ 
tation  of  the  example.  This  is  because  the  exam¬ 
ple  is  not  just  not  a  predicat«-r«latioii-lor», 
but  it  is  also  a  lunction-lor»,  a  different  (but 
similar)  construct  which  can  be  contrasted  with  the 
pr  «di  cat  e-r  «lat  ion-form.  Additional  text  is  gener¬ 
ated  first  to  introduce  the  negative  example  as  a  contrast 
to  the  positive  ones,  and  then  to  explain  the  differences 
between  the  two  similar  consuncts. 

This  scenario  also  illustrates  the  other  aspects  that  have  to 
be  taken  into  consideration  when  generating  integrated  text 
and  examples: 

1.  It  is  not  enough  to  know  the  important  features  to  con¬ 
vey.  The  system  also  has  to  differentiate  between  vari¬ 
able  f  enures  and  fixed  features.  Fixed  features  are 
those  that  cannot  vary.  In  this  scenario,  the  fact  that  a 
pr«<licat«-r«lation-f  orm  must  begin  and  end  with 
a  parenthesis  is  a  fixed  feature.  On  the  other  hand,  vari¬ 
able  features  are  those  which  can  vary  within  a  certain 
range  in  a  positive  example  -  in  this  case,  the  relation- 
name  is  a  variable  feature.  It  is  usually  necessary  to 
provide  sev^al  examples  to  communicate  the  variable 
nature  of  the  feature  [Clark,  1971].  In  this  case,  several 
relation  names  are  used  in  an  attempt  to  ensure  the  user 
realizes  their  variable  natiue.  On  the  other  hand,  it  is 
not  always  necessary  to  explicitly  state  fixed  features,  as 
they  will  become  obvious  from  examples. 

2.  The  presentation  order  of  the  examples  is  especially  im¬ 
portant  to  communicate  the  criticalfeatures  of  a  concept. 


A  predicate-form  is  a  restricled-cxpression.  It  returns 
a  boolean  value,  and  the  number  of  arguments  in  a 
predicate-form  is  equal  to  the  arity  of  Cbe  relation. 

A  predicate-form  can  be  of  three  types:  a  predicate- 
relatioo-form.  a  predicate-action-form.  or  a  predicate- 
logical-form. 

A  predicate-relation-form  is  a  relation-name  followed 
by  some  arguments.  The  arguments  are  restricted- 
expressions,  such  os  variables,  concepts,  function-forms 
and  predicate-forms.  Examples  of  predicate-relation- 
forms  are: 

(IIDICAT0R-ST4TB  LBD-1  01) 

(HiRDUARE-STATUS  LAIBRIDCE-2  FAULTY) 
(COMBCTKD-TO  DECSERVER-1  VAX-A) 

However,  the  following  example  is  not  a  predicate- 
relation-form,  but  a  function -form,  because  the  number 
of  arguments  is  not  equal  to  the  arity  of  the  relation: 

(COIIECTBD-TO  DECSERVER-1) 

The  difference  between  a  function-form  and  a  predicate- 
relation-form  is  that  the  function-form  takes  one  less  ar¬ 
gument  than  the  arity  of  the  relation,  and  returns  the  range 
of  the  relation,  while  the  predicate-logical-form  takes  as 
many  arguments  as  the  arity  and  returns  a  boolean  value. 

A  predicate-action-form  is  . . . 

Figure  3:  The  documentation  for  ‘predicate-form’. 

Critical  features  are  features  which,  if  modified,  cause 
the  example  to  change  from  positive  to  negative.  In  this 
case,  the  relationship  between  the  arity  and  the  number 
of  arguments  is  a  critical  feature.  By  conu-asting  the 
third  and  fourth  example,  which  are  identical  except  for 
the  number  of  arguments,  the  pair  highlights  the  crit¬ 
ical  feature.  In  general,  examples  should  be  pairwise 
maximally  different  if  they  are  positive  examples,  and 
minimally  different  if  they  are  a  positive-negative  pair 
[Feldman,  1972]. 

We  now  describe  how  our  generation  system  can  generate 
integrated  explanations,  and  present  a  uace  of  the  system  as 
it  generates  the  explanation  presented  in  this  scenario. 

4.1  The  Generation  Framework 

Our  framework  implements  the  integration  of  text  and  ex¬ 
ample  within  a  text-generation  system.  More  specifically, 
we  use  a  text-planning  system  that  constructs  text  by  explic¬ 
itly  reasoning  about  the  communicative  goal  to  be  achieved, 
as  well  as  how  goals  relate  to  each  other  rhetorically  to 
form  a  coherent  text  [Moore  and  Paris,  1989;  Moore,  1989; 
Moore  and  Paris,  1992],  Given  a  top  level  commu¬ 
nicative  goal  (such  as  (KIOW-ABOUT  HEARER  (COiCEPT 
PREDICATE-FORM)),*  the  system  finds  plans  capable  of 
achieving  this  goal.  Plans  typically  post  further  sub-goals 
to  be  satisfied.  These  are  expanded,  and  planning  continues 
until  primitive  speech  acts  are  achieved.  The  result  of  the 
planning  process  is  a  discourse  tree,  where  the  nodes  repre¬ 
sent  goals  at  various  levels  of  abstraction,  with  the  root  being 
the  initial  goal,  and  the  leaves  representing  primitive  real- 

*Sce  the  references  given  above  for  details  on  the  notation  used 
to  represent  these  goals. 
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( define-teit-pbm-operator 
.‘effect  (know-about  H  (concept  7c)) 

:ooiistralnU  (and  (isa?  ?c  object) 

(Ua?  7c  7parent)) 

:Buckiia  (bel  H  (isa  7c  7paient)) 

:sateilites  (((elaboratioo  7concept)  'optional*))) 

( define>text>plaB-operator 
:effect  (elaboration  7concept) 
iconstralnts  (disjoint-covering  7c  7d-c) 
iDuckus  ((setq  7d-j  (order-maxim-of-end-weigfat  7d-c)) 
(inform  S  H  (disjoint-cover  7c  7d-j))) 

:aatellites  (((foreacb  7d-j  (know-about  H  (7d-j  given  7c)))))) 

Figure  4:  Some  sample  plans  from  our  application. 


ization  statements,  such  as  (IIFOKN  . . . )  statements.  The 
discourse  tree  also  includes  coherence  relations  [Mann  and 
Thompson,  1987],  which  indicate  how  the  various  portions 
of  text  resulting  from  the  discourse  tree  will  be  related  rhetor¬ 
ically.  This  tree  is  then  passed  to  a  grammar  interface  which 
converts  it  into  a  set  of  inputs  suitable  for  input  to  a  grammar. 

Plan  operators  can  be  seen  as  small  schemas  which  describe 
bow  to  achieve  a  goal;  they  are  designed  by  studying  natural 
language  texts  and  transcripts.  They  include  conditions  for 
their  applicability,  which  can  refer  to  the  system  knowledge 
base,  the  user  model,  or  the  context  (the  current  text  plan  tree 
and  the  dialogue  history).  TWo  of  the  plan  operators  used 
in  our  system  are  shown  in  Fig.  4.  The  first  one  is  used  to 
describe  objects  by  describing  a  concept  in  terms  of  its  parent 
and  possibly  elaborating  on  this  description.  The  second  one 
can  be  used  to  elaborate  upon  a  description  by  describing  the 
sub-types  of  a  concept. 

Using  this  framework,  the  generation  of  examples  can  be 
accomplished  by  explicitly  posting  the  goals  of  providing 
examples  while  constructing  the  text,  i.e.,  some  of  the  plan 
operators  include  the  generation  of  examples  as  one  of  their 
steps.  This  ensures  that  the  examples  embody  specific  infor¬ 
mation  that  either  illustrates  or  complements  the  information 
in  the  accompanying  textual  description,  and  that  the  text  to 
be  generated  will  reflect  the  presence  of  examples.  The  con¬ 
straints  of  the  plan  operators  indicate  bow  the  text  and  the 
examples  co-constrain  each  other.  Because  the  same  plan¬ 
ning  mechanism  is  used  to  plan  the  text  and  the  examples, 
integration  is  achieved  in  a  straightforward  way. 

42  A  IVace  of  the  System 

We  illustrate  how  our  system  integrates  text  and  examples 
by  working  through  the  geno'ation  of  the  example  shown 
in  Fig.  3,  that  is,  a  description  of  a  grammar  conc^t  for  a 
non-expert  user. 

The  system  initially  begins  with  the  top-level  goal: 
(XIOV-ABOUT  H  (COICEPT  PREDICATE-FORM)). The  text 
planner  searches  for  applicable  plan  operators,  and,  finding 
the  first  plan  presented  in  Fig.  4,*  posts  the  two  subgoals  in¬ 
dicated  in  the  plan:  one  to  give  a  make  the  hearer  believe  that 
(pr«dicata-f  orm)  is  a  raatrictad-axpratsion  (its  par¬ 
ent  in  the  Loom  hierarchy),  and  another  (optional)  to  provide 
more  information  (elaborate). 

*Wben  several  plans  are  available,  the  system  chooses  one  using 
selection  heuristics  designed  by  IMoore,  1989]. 
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Figure  5:  A  skeletal  fragment  of  the  text  plan  generated  for 
the  initial  text. 


At  this  point,  the  discourse  tree  has  two  un¬ 
expanded  nodes:  (BEL  H  (ISA  PREDICATE-FORK  REST¬ 
RICTED-FORM))  and  (ELABORATIOI  PREDICATE-FORM). 
The  planno*  expands  the  first  subgoal  by  first  indicat¬ 
ing  the  conc^t-parent  relationship  (“a  predicate  form 
is  a  restricted  expression”)  and  then  informing  the 
user  of  the  attributes  differentiating  a  pradicate-f on 
from  a  restricted-exprassion  (”it  returns  a  boolean 
value . . .  ”). 

The  goal  to  elaborate  upon  a  concept  is  expanded  in 
turn.  The  plan  chosen  here  is  the  one  shown  in  Fig.  4, 
which  presents  the  diffwent  types  of  pradicata-f  ons  that 
exist,  namely  pradicata-ralation-fon,  pradicata- 
action-fon,  and  pradicata-logical-fon.  Because 
these  sub-types  might  be  of  differing  complexity,  and  it 
is  important  to  present  the  information  from  the  sim¬ 
plest  one  to  the  most  complex  one  (according  to  the 
maxim  of  end-weight  in  linguistics  [Werth,  1984]),  one 
step  of  the  plan  operator  explicitly  orders  the  sub-types  be¬ 
fore  presenting  them  to  the  user.  This  ordering  is  done 
based  on  some  general  complexity  heuristics:  in  this  case, 
pradicata-action-lora  is  considered  more  complex  than 
pradicata-ralation-for«  because  it  is  allowed  to  have 
an  action-f  or*  (a  goal-posting  construct)  as  one  of  its  argu¬ 
ments.  The  pradicata-logical-forais  considered  most 
complex  because  it  is  recursive  in  definition.  After  informing 
the  user  of  the  sub-types,  goals  to  elaborate  upon  each  of  the 
sub-types  are  posted  and  expanded  in  turn.  E^h  such  elabo¬ 
ration  results  in  posting  the  goal  of  describing  each  sub-type. 
This  portion  of  the  planning  process  is  recorded  in  the  skeletal 
text-plan  shown  in  Fig.  5.' 

Let’s  consider  the  expansion  of  tl.e  goal:  (KlOVf-ABOUT  H 
(COICEPT  PREDICATE-RELATIOl-FORM)).  Unlike  for  the 


^All  the  text  plans  shown  in  this  paper  are  simplified  versions  of 
the  actual  plans  generated;  they  do  not  show  the  coherence  relations 
that  hold  between  the  text  spans  resulting  from  this  planning,  and 
the  communicative  goals  are  not  written  in  their  formal  notation,  i 
terms  of  the  hearer's  mental  states,  for  readability's  sake. 
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Figure  6:  Plan  fragment  for  the  predicate-relation-fonn. 


similar  initial  goal  given  to  the  system,  the  system  does 
not  pick  the  operator  that  defines  the  concept  in  terms  of 
its  parent,  since  the  concept-parent  relationship  between  a 
predicatc-relation-lorm  and  a  predicate-fon  has 
already  been  mentioned  (since  pradicate-relation-lorK 
was  introduced  as  a  sub-type  of  pr«dicata-for»).  In¬ 
stead,  a  plan  operator  that  describes  the  concept  syntax  is 
chosen.  In  this  case,  the  syntax  is;  (  relation-nane 
arguments'*'  ). 

Instantiating  the  plan,  the  system  realizes  that  it  can  de¬ 
scribe  the  syntax  by  both  text  or  examples  (from  the  syntax 
definition,  the  system  attempts  to  construct  examples  that 
match  this  syntax).  The  steps  of  the  plan  operator  now  com¬ 
pute  the  parameters  that  determine  what  get  explained  via  text, 
via  examples  or  both.  In  this  case,  the  system  determines* 
that  there  is  one  critical  feature,  i.e.,  the  number  of  argu¬ 
ments  in  the  predicat«-relation-lor«  must  be  equal  to 
the  arity  of  the  relation,  and  one  variable  feature,  i.e.,  the 
ralation-naaa. 

At  this  point,  the  system  aisu  deierinines  ihai  Uie  parenthc 
ses  do  not  need  to  be  mentioned  in  the  text  as  they  will  be 
mentioned  in  all  the  examples,  are  fixed-features,  and  more 
than  one  example  will  be  presented.  The  system  now  has 
enough  information  to  continue  with  the  presentation  plan¬ 
ning  process:  it  constructs  the  text:  “a  predicate-relation- 
form  is  a  relation-name  followed  by  . . .  ”,  and  posts  a  goal 
to  generate  examples.  The  plan  chosen  to  achieve  this  goal 
posts  the  goal  to  generate  text  to  introduce  the  examples  for 
the  variable  features  as  background,  the  goal  to  generate  the 
examples  for  the  variable  feature,  and  the  goal  to  generate 
examples  for  the  critical  features. 

The  system  picks  two  positive  examples  to  illustrate  the 
variable  feature.  In  general,  as  mentioned  before,  adjacent 
positive  examples  must  be  as  different  from  one  another  as 
possible.  Inthiscase,  the  system  picks  two  different  relations. 

'The  system  determines  critical  features  and  variable  features 
by  modifying  the  definitions  and  seeing  whether  an  example  of  the 
modified  definition  becomes  a  negative  example  of  the  concept, 
using  the  Loom  classifier. 
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Figure  7:  Text-plan  fragment  for  the  generation  of  the  exam¬ 
ples  for  the  critical  feature. 


and  the  first  two  examples  are  generated.  This  part  of  the  text 
plan  is  shown  in  Rg.  6. 

Now  the  system  must  generate  an  example  for  the 
critical  featitfe,  i.e.,  that  the  number  of  arguments  of  a 
pr«dicata-relation-f  ozs  must  be  equal  to  the  arity  of 
the  relation.  Because  this  is  a  critical  feature,  the  system 
decides  to  generate  one  pair  of  positive-negative  examples  to 
highlight  the  feature.  The  positive  example  of  the  pair  will  be 
presented  first  because  the  discourse  tree  shows  that  positive 
examples  were  already  given  and  introduced  with  text.  It  is 
thus  possible  to  simply  give  a  new  positive  example  without 
introducing  it.  To  present  the  negative  example,  the  system 
posts  the  goal  of  contrasting  the  positive  example  given. 

There  are  two  ways  in  which  a  negative  example  can  be 
constructed  in  this  case;  by  changing  the  number  of  argu¬ 
ments  from  two  to  three,  or  from  two  to  one.  The  system  con¬ 
structs  descriptions  of  both  types,  and  checks  to  see  whether 
one  of  these  is  a  known  concept  (this  can  done  easily  using  the 
classifier  in  Loom).  It  finds  that  a  relation  with  one  argument 
is  a  construct  in  the  grammar,  namely  a  lunction-f  orn.  It 
thus  uses  that  as  a  negative  example,  after  posting  the  appro¬ 
priate  goal  to  generate  text  to  inuoduce  the  example.  It  also 
posts  a  goal  to  elaborate  with  text  on  the  differences  between 
a  function-f  on  and  a  pr«di cat «-relat ion-ton  to 
ensure  that  the  user  is  not  further  confused  by  the  use  of  a 
(possibly)  new  term.  The  relevant  portions  of  the  text-plan 
are  shown  in  Fig.  7. 

The  planner  continues  expanding  goals  in  this  fashion,  un¬ 
til  all  the  goals  are  primitive  speech-acts  (such  as  IIFORM). 
Finally,  the  completed  discourse  tree  is  passed  to  an  inter¬ 
face  which  converts  the  IIFORM  goals  into  the  appropriate 
input  for  the  sentence  generator.  The  interface  chooses  the 
appropriate  lexical  and  syntactic  constructs  to  form  the  indi¬ 
vidual  sentences  and  connects  them  sqipropriately,  using  the 
rhetorical  information  from  the  discourse  tree.  For  example. 


n 


it  chooses  “However”  to  reflect  the  COITRAST  relation. 

5  Conclusions  and  Future  Work 

In  this  paper,  we  have  shown  how  examples  and  text  interact 
with  and  co-constrain  each  other.  It  is  important  to  recog¬ 
nize  this  intQ-action  in  order  to  provide  an  appropriate,  well- 
structured  and  coherent  presentation  to  the  user.  We  have 
also  argued  that  a  generation  system  capable  of  providing 
examples  as  part  of  its  presentation  must  consider  example 
generation  as  an  integral  part  of  the  generation  process.  We 
have  presented  our  documentation  system  which  illustrates 
this  idea. 

While  our  system  is  already  capable  of  generating  inte¬ 
grated  text  and  examples,  some  issues  remain  to  be  studied. 
In  particular,  we  want  to  investigate  issues  related  to  goal 
(and  example)  interaction  at  a  more  global  level  than  cur¬ 
rently  done:  that  is,  how  can  a  system  ‘Ye-use”  an  example 
that  was  given  to  illustrate  a  different  concept  in  a  previous 
part  of  the  dialogue. 
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